%This template was prepared by Dr G J Gibbon
%School of Electrical and Information Engineering
%University of the Witwatersrand
%25/3/2001
%This simple format to be used for reports submitted to the School
%The table of contents may not be necessary for short reports
%
%
%rename (the name you want) this document with extension .tex

\documentclass[10pt,twocolumn]{witseiepaper}
\usepackage{KJN}
%\usepackage{stfloats}
\usepackage{dblfloatfix}
%\usepackage{fixltx2e}
\usepackage{ctable}
%
% PDF Info
%
\ifpdf
\pdfinfo{
/Title (Software III Project - Jam Dodge - Preliminary Report v1.0)
/Author (Benji M. Sim; Alec Larsen; Mitchell Cox)
/CreationDate (D:201103281301)
/ModDate (D:201103300655)
/Subject (ELEN4009, 2011)
/Keywords (ELEN4009, Architecture, witsmorabaraba)
}
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\begin{document}

\title{Software III Project - Jam Dodge - Preliminary Report v1.0}

\author{Mitchell Cox, Alec Larsen, Benjamin M. Sim
\thanks{School of Electrical \& Information Engineering, University of the
Witwatersrand, Private Bag 3, 2050, Johannesburg, South Africa}
}


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
%
\abstract{The high-level design for a mobile device based traffic monitoring system is presented. The system is to be used by the average motorist for accurate, near, real-time traffic information. The system client and server side systems is discussed. The client side logs GPS positioning information to the server. The information logged can then be viewed on a map with traffic intensity overlays. System success criteria have been defined and the development approach defined.}

\keywords{ELEN4010, traffic monitoring, Google maps, mobile, GPS}

\maketitle

\thispagestyle{empty}\pagestyle{empty}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% INTRODUCTION
\section{Introduction}
With the increasing trend toward urbanization \cite{urbanization} city road systems are becoming ever more congested. A system to provide accurate near real-time monitoring of this problem is becoming ever more necessary, for both the individual and government. Jam-Dodge seeks to facilitate this need by providing the traffic information via motorists mobile devices.\\
\\
Using the devices Global Positioning System (GPS) and Internet capabilities, positional points can be logged and uploaded to a central repository to be viewable from a variety of devices. Systems for near real-time traffic monitoring are not new with existing systems using both satellite information \cite{satelite_traffic} and mobile devices \cite{cellint, gps_based_road_traffic, google_maps}.\\
\\
The proposed system uses a revised client server approach. The client side, on a mobile device, logs the positional points over a period and then uploads this to the web server. The web server back-end then interprets the data and stores it as necessary in a data storage system. The information stored is the used by the web front-end in order to display the necessary information to the user, on either their mobile device or a computer. The following is a high level design discussion on the proposed solution.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% DOCUMENT BODY
%%%%%%%%%%%%%%%%%%% System Requrements Section %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{System Requirements}
\label{sec:spec}
\subsection{Purpose}
Jam-Dodge aims to facilitate a need for near real-time traffic monitoring, by uploading user logs with location data. The data will be logged with the users mobile device. The information then needs to be easily accessible to the user, in an intuitive and understandable manner.
\subsection{Target}
Traffic information is a necessity to people using vehicular transport. Consequently the application needs to target users whom have little to no technical nous.
\subsection{Assumptions and Dependencies}
\label{sec:system_requirements_ass_depen}
The application will require that the user has a mobile device with GPS functionality and a form of mobile Internet. Additionally the system will be written, initially, for the Android Operating System (OS).
\subsection{Functions}
The required functionality for the system is detailed in more depth in appendix \ref{appen:use_cases}, however a summarised discussion will be given here.
\begin{itemize}
\item Viewable map with traffic overlay available from a Personal Computer (PC).
\item Viewable map with traffic overlay available from a Mobile Device.
\item Intuitive install of the client side software.
\item Intuitive front-end to web server.
\item Anonymous data transmission and user confidentiality.
\item Access only to users whom supply traffic information.
\item Efficient use of mobile device resources, namely battery and bandwidth.
\item Automatic identification of operating region, for use in roaming.
\item Automatic detection of transport mode.
\end{itemize}
\subsection{External Interface Requirements}
\subsubsection{User Interfaces}
The user interfaces, for both the client side software and web server front-end, need to be simplistic and reflect the level of the target audience. To support scalability the viewable interfaces should be web based.
\subsubsection{Hardware Interfaces}
The client side software will be required to interface with the mobile devices built in GPS.
\subsubsection{Software Interfaces}
The web server front and back-ends interface through software. No explicit interface means need to be defined.
\subsubsection{Communication Interfaces}
Communication needs to occur between the users mobile device and the server font end. Hence a protocol needs to be described to cater for this communication.
\subsection{Performance Requirements}
The system needs to operate efficiently on both the client and server sides. The server side however, will be under a larger load, handling both the incoming user data and traffic map requests. The system will be deemed unsuccessful if excessive wait times are experienced. 

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Solution Section %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Solution Overview}
The system is comprised of five parts; client side software, web server front-end, web server back-end, data storage and a communication protocol. Figure \ref{fig:entire_system} shows the entire system with all the components, the communication protocol being the interface between the service and the web server back-end.

\begin{figure}[!ht]
\centering
\includegraphics[width=7cm]{entire_system.jpg}
\caption{An overview of the entire Jam-Dodge system.}
\label{fig:entire_system}
\end{figure}

%%%%%%%%%%%%%%%%%%%% Client Side Application Section %%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Client Side Software}
\label{solution_client_side}
The software written will run on an Android phone, section \ref{sec:system_requirements_ass_depen}, with possible extensions to both Blackberry OS and iOS, for iPhones.\\
\\
%The software that runs on the mobile device will be initially written to run on %an Android platform. The project can eventually be extended to run on platforms %such as iPhone and Blackberry, but for the purpose of the project only Android %will be used.\\
%\\
The mobile software is comprised of two parts: a service to log location points and an application that the user can interact with, described in section \ref{sec:client_side_service} and \ref{sec:client_side_application}.

\subsubsection{Service}
\label{sec:client_side_service}
The service (or daemon) is installed on the mobile device. The service will start automatically on device initialisation. The user may manually disable the service if so desired but, the service will reinitialise if the device is rebooted. Disabling the service for an extended period will result in the access to the traffic map web page being revoked.\\
\\
The service should be invisible to the user. However, as a later extended function the service may be able to inform the user of upcoming exceptional incidents on the road. During normal operation the service will periodically turn on the devices GPS to check if the device is on a road, and if it is, the service will start logging traffic data to the server. Details of the protocol used can be found in section \ref{sec:communication_protocol}. Once the device leaves the road, the service returns to its periodic checking mode and will not log any data.

\subsubsection{Application}
\label{sec:client_side_application}
The application presented to the user is extremely simple. It provides limited settings for the installed service as well functionality to view the device ID so that the mapping service can be used on other devices such as a PC. The application's main screen is filled with a map which is normally centred on the user's location, overlaid with available traffic data.\\
\\
The map screen is actually a web viewer embedded into the application which displays the web front-end map page. Because the main application intelligence (the map with overlays) is centralised to the web page, the actual Android (or other platform) application need not be complex.

%%%%%%%%%%%%%%%%%%%% Web Server Front-End Section %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Web Server Front-End}
As mentioned in Section \ref{sec:client_side_application} the Map viewing application is web-based (most probably a PHP implementation) and can be viewed on either the mobile device (initially Android based devices) or on a PC. However, Jam Dodge is a give-and-take based service: to model traffic density, data is required. Hence in order for the users to use the service they must supply data.  Therefore when the user accesses the front-end it will check to see if he/she has supplied data within a certain period of time (this will be adjustable by the developers in order to balance the trade-off between user satisfaction and the amount of data supplied by the users). This check will occur during the PC login process (Appendix \ref{appen:frontend}, Figure \ref{fig:frontend_login}) or during the Android Setup process (Appendix \ref{appen:frontend}, Figure \ref{fig:frontend}) according to which device the application is being viewed on. Therefore a check is required to see what device the application is being viewed on. The front-end will respond accordingly (Appendix \ref{appen:frontend}, Figure \ref{fig:frontend}).\\
\\
The PC Setup will attempt to use the W3C Geo-location \cite{georef} standard to find the position of the user's PC. The user is able to manually enter their current address if they want to override this functionality. A map centre variable is given the value of the current address. This setup will also resize the map accordingly.\\
\\
The Android Setup will attempt to use the device's GPS capability to position the user. The user is able to manually enter their current address if they want to override this functionality. The map centre variable is given the value of the current address. This setup will also resize the map accordingly.\\
\\
The Platform Independent Setup initialises variables to track the map's boundaries (in terms of the most North East and South West co-ordinates being displayed on the map \cite{mapref}). This allows the system to automatically update the overlays to be displayed on the map when the user scrolls the map or zooms in. There will be a threshold time before the overlays are updated to prevent the application overlays updating while the user is scrolling which could slow down the scrolling process.

%%%%%%%%%%%%%%%%%%%% Web Server Back-End Section %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Web Server Back-End}
The back-end server facilitates the control of information flowing between the client side daemon, the web front-end and the data storage. It serves the information to or from these components as necessary. Figure \ref{fig:backend} depicts the flow diagram for the back-end web server. 

\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{backend.jpg}
\caption{The flow diagram for the web server back-end.}
\label{fig:backend}
\end{figure}

Additionally the back-end needs to intelligently interpret the data coming from the mobile device, removing the load from the mobile device. This centralised approach is ideal for a mobile platform, due to their limited processing power. Additionally, this approach is highly scalable.
%%%%%%%%%%%%%%%%%%%% Database Section %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Data Storage}
A MySQL \cite{MySQL_ref} Database will be used for the data storage. Data will be stored and retrieved from the database by the web server back-end. The database will store both user and traffic information in the necessary tables.\\
\\
The table structure, as defined in figure \ref{fig:database}, consists of three distinct tables. Firstly the user table stores a unique identification number for that user, the users unique salted hash, see section \ref{sec:communication_protocol}, and last recorded information log. The actual traffic data is stored in two separate tables. Firstly a table with the segment geographical position and its unique identifier. And the second table contains all the relevant traffic information for that point. Using relevant Structured Query Language calls the necessary information can be retrieved.

\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{Database.jpg}
\caption{The database table structure.}
\label{fig:database}
\end{figure}

%%%%%%%%%%%%%%%%%%%% Communication Protocol Section %%%%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Communication Protocol}
\label{sec:communication_protocol}
\subsubsection{Brief Description}
The protocol consists of two types of communications which are described below: periodic server checks and data commits.\\
\\
Packets are sent over a TCP socket which forms the connection between the mobile device and the server. The amount of data transferred is minimal in order to conserve bandwidth. Compression schemes should be implemented on all data before transfer as well as encryption to protect the privacy of the user.

\subsubsection{ID Number}
Each mobile device that connects to the server requires a unique ID number to identify itself. Initially this number is used to track whether a user is uploading data however it could be used for various other possible purposes. The number cannot be used to track a specific user as it is essentially randomly generated when a user first downloads the application to a device.\\
\\
The number is generated by adding a random number between 1 and 100 to the mobile devices IMEI \cite{imei} number and then running the result through a CRC32 \cite{crc32} hash generator. This number is therefore approximately unique to within the uniqueness of a CRC32 hash. It is not critical to the operation of the application that the number is unique, as a few non-unique ID's will not hinder the operation of the system.\\
\\
Because a random number was added to the IMEA number, it is impossible to determine the original IMEA number and so user privacy in guaranteed by the protocol. It is however still possible to trace a user's data by checking their IP address, but this is overcome by packet encryption.

\subsubsection{Periodic Server Updates}
When the mobile device is not in data commit mode it needs to periodically check whether it's position is on a road so that it can enable the data commit mode or not. The time between checks is set automatically by the server, which incorporates the settings updates in the 'Params' part of its reply message. Figure \ref{fig:mobile_server_message_flow} below illustrates the message flow as well as data contained in each message. Specific packet structure is detailed in figure \ref{fig:periodic_packet_message.jpg}.

\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{mobile_server_message_flow.jpg}
\caption{Message flow of a periodic server update}
\label{fig:mobile_server_message_flow}
\end{figure}

Exact names and values for parameters will be defined later in the project when there is a requirement for them. It is also allowed that the server response contains no parameters. Position values are in a latitude longitude format with decimal degrees, separated by a space. Lines are always separated with a newline character that should not be platform specific.

\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{periodic_packet_messages.jpg}
\caption{Packet description for mobile-to-server packet (left) and server response (right).}
\label{fig:periodic_packet_message.jpg}
\end{figure}

\subsubsection{Data Commits}
When the mobile device receives confirmation that it is located on a road it switches to data commit mode where packets are sent at regular intervals to the server containing position data for the server to process.\\
\\
The message flow and packet details are shown in Figure \ref{fig:data_commit_message_flow} and \ref{fig:commit_packet_message} respectively.

\begin{figure}[!ht]
\centering
\includegraphics[width=8cm]{Data_commit_message_flow.jpg}
\caption{Data commit message flow.}
\label{fig:data_commit_message_flow}
\end{figure}

As can be seen from Figure \ref{fig:commit_packet_message}, in data commit mode the server rarely sends responses to the mobile device. Technically, the underlying TCP protocol does cause messages to be sent from the server to the mobile device, but are not strictly relevant to this description. The only time the server sends to the mobile device in data commit mode is when the device leaves the road and hence can return to periodic server update mode.

\begin{figure}[width=8cm][ht!]
\centering
\includegraphics{commit_packet_message.jpg}
\caption{Data commit packet description.}
\label{fig:commit_packet_message}
\end{figure}

The 'Time' value is the timestamp in coordinated universal time (UTC) of the coordinate that follows. The server uses this timestamp to calculate the speed between points. The number of points that gets sent to the server in each commit is automatically set by the server via a parameter update, as discussed in Section (before). The time between points is also automatically set during a parameter update, but cannot be strictly adhered to for various reasons, which is why the timestamp is included.

%%%%%%%%%%%%%%%%%%%%%%%% Project Management Section %%%%%%%%%%%%%%%%%%%%%%%%%%%
\section{Project Management}
\subsection{Iterative Approach}
The iterative development approach to be used in the development of Jam Dodge is a modified version of SCRUM \cite{scrumref}. The SCRUM methodology defines Sprints - development stages during which a subset (referred to as the Sprint backlog) of the overall requirements (referred to as the Product backlog) is planned to be implemented.\\
\\
The Product Owner (usually the customer) informs the development team what functionality is needed in a Sprint. The development team then decides, at the Sprint planning meeting, which of this functionality is possible to implement in the Sprint by creating the Sprint backlog. The functionality in the Sprint backlog (referred to as goals) is broken up into simpler functionality called stories. Functionality from the Sprint backlog that is incomplete at the end of a Sprint is put back into the Product backlog.\\
\\ 
The Scrum Master is the person that manages the Sprints. Usually with SCRUM, the development team meets every day to discuss what stories each developer has been working on, the progress on these stories, time worked on these stories and estimated time left to complete these stories. Daily meetings are impractical as the development team consists of students and hence the development of Jam Dodge is not their sole focus. SCRUM has been modified to have longer Sprints with only weekly Sprint meetings (as there should be progress on a weekly basis).\\
\\
SCRUM focuses on delivering functionality in each Sprint and tends to neglect that research, design and documentation also takes time. Hence we have modified the approach to include a Research and Design Sprint (where goals are defined in terms of research and design criteria instead of functionality) and two Development Sprints (during which the primary goal is integrating functionality in the Sprint backlog). Hence there are three iterations in the development process. More details on the three Sprints see Appendix \ref{appen:scrum_iterations}.\\
\\
At the time of writing this document the Research and Design Sprint has been completed. The Sprint document is attached to the back of this report.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Performance Apprasail %%%%%%%%%%%%%%%%%%%%%%%%%
\subsection{Performance Appraisal}
To assess the performance, and hence the success of the system a few test criteria need to be defined. These criteria, listed below, are system critical if one or more of the tests is deemed to have failed the system will be considered a failure. However successful passing of all tests does not necessitate a successful system.\\
\\
The key pass criteria are:\\
\begin{itemize}
	\item The service correctly captures the GPS location points.
	\item The service correctly communicates the points to the web server back-end.
	\item The web server back-end correctly logs the received positional points to the data storage system.
	\item The data storage system can efficiently recover information requested by the web server back-end. 
	\item The system is secure and users privacy is maintained.
	\item The web server front-end correctly generates the provided information into easily understandable image overlays.
\end{itemize}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% Cost Analysis Section %%%%%%%%%%%%%%%%%%%%%%%%%
\section{Costing Analysis}
The Jam Dodge application will be free for anyone to download and use. The only costs associated with its use are data charges from the uploading of traffic data from mobile devices to the server and the downloading of data in the form of maps and traffic overlays.\\
\\
The cost of the continuous uploading could be a concern for some users. It has been calculated that the service that runs on their mobile device will use approximately 5 kilobytes per hour of driving. At a data cost of R2.00 per megabyte this equates to R0.01 per hour of driving, see appendix \ref{appen:costing_analysis}. The usage per day of no driving is approximately R0.01. If compression is not used on the data, the price approximately doubles, but is still of no concern.\\
\\
Even if many more data points are logged, the price is still a matter of cents. Because of the efficiency of the service, users will not have to worry about data usage by the service and should be happy to leave the service running at all times.
\\
The costs for running the server will initially be covered by the developers, but once the project gains popularity, advertising can be incorporated into the application and web site to generate revenue.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% CONCLUSION
\section{Conclusion}
The Jam-Dodge system proposed adheres to all the criteria defined in section \ref{sec:spec}. However, as this is only a high level design the system it is expected that the system will require modifications to create a successful release candidate of Jam-Dodge.

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% REFERENCES

\bibliographystyle{witseie}
\bibliography{Database}

%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
% APPENDICES
\clearpage
\appendix
\section{Use Cases}
\label{appen:use_cases}
\subsection{Access Website from PC}
When a user accesses the Jam Dodge web site from a PC, the user will be presented with a welcome page that describes the service. The page will also have an easy to use 'login' where the user's ID can be entered to gain access to a map page that has traffic overlays. The ID can be found easily in a menu
on the mobile device application that can be installed.\\
\\
A message is also present and clearly visible that if the user wishes to use the service they must download and install the application onto their mobile phone or other compatible device.
\subsection{Access from Mobile Device}
When a user accesses the web site from a mobile phone a stripped down page is presented that contains a description of the service and a download link. A link to the actual site is also present, allowing access to the mapping facilities from any web connected device.
\subsection{Access with Dormant Account}
When a user has an account (the application is installed on a mobile device), but the user has manually disabled the service from uploading data for a long period of time such as two weeks, the user will no longer be allowed to view the Jam Dodge maps or use any other services. This ban will be in effect until
the user has uploaded a certain amount of useable data.
\subsection{Disabling the Service}
The user may want to temporarily disable the service from uploading data for various reasons such as low battery or lack of airtime. This is possible from the settings menu on the application that was installed.\\
\\
The service will automatically disable itself temporarily in certain cases: when the service detects a low battery state on the device, it will disable until the battery is recharged. It will be possible to tell the service to disable itself while oversees (roaming) to save on data charges. If the service is run while in a country that is not allowed, then the service will disable itself.\\
\\
When the mobile device is turned on the service will display a prompt (pop-up) message notifying the user that it is disabled. This message will be non-intrusive and will disappear after a few seconds.
\subsection{Installable from Mobile Device}
After the application is downloaded it must be installed. The installation process installs an icon for the user to access the application and it also installs the service which will run in the background every time the device is turned on. When the service is started for the first time it checks a configuration file for a unique ID. If none is found then one is generated.
\subsection{Using Jam Dodge in a disabled Region}
It may be required that certain regions around the world should not be able to access the service. In this case, a warning will be displayed on the web site according to their detected location.\\
\\
The user will still be able to install the application, but when it is running it will display warnings to the user that it is disabled along with the reason. The service will reactivate itself automatically if and when the region is allowed.
\subsection{Differentiating between vehicular and manual transport modes}
Since the service runs continuously on a mobile device such as a cell phone, it gives rise to some problems in certain cases. One problem is that a user might have their mobile phone in their pocket and be running, walking or riding their bicycle on or near a road. In this case it is possible that data will be interpreted as slow moving traffic, as opposed to being ignored.\\
\\
A solution to this problem requires research, but an intuitive initial solution would be to ignore all speeds slower than an average bicycle, or to take them into account but weight them much lower than faster speeds.

\section{Scrum Iterations}
\label{appen:scrum_iterations}
\subsection{Research and Design Sprint}
Date: 27 February 2011 - 1 April 2011\\
\\
Participants: Mitchell Cox, Benji Sim and Alec Larsen\\
\\
Description: The goal of this sprint is to come up with a software application that uses a Maps API and derive requirements for the application. A Subversion repository needs to be setup which will allow the developers to work on the different parts of the application. Research needs to be conducted on the use of the Android SDK. Additional research must be done into use of a Maps API such as one of the Google Maps APIs. The research done will allow for a high level design to be done. The licence of the software application must be established but this can change as we see fit during the development cycle. This must all be documented in the High Level Design Document by the end of this sprint.
\subsection{Component Creation Sprint}
Date: 2 April 2011 - 3 May 2011\\
\\
Participants: Mitchell Cox, Benji Sim and Alec Larsen\\
\\
Description: The goal of this sprint is to complete the following components of the system: Web front-end, Android Daemon, Web back-end and the Database Management System. Each developer will work on a component using test data and will conglomerate efforts to work on the web back-end which is a substantial portion of the project. Each component needs to be documented excellently.
\subsection{Integration, Validation and Documentation Sprint}
Date: 4 May 2011 - 5 June 2011\\
\\
Participants: Mitchell Cox, Benji Sim and Alec Larsen\\
\\
Description: The goal of this sprint is to completely integrate the components of the software application, test and validate that the system works as expected. It is also necessary that each developer gains an understanding of the entire system through the component documentation derived in the previous sprint. Each developer must complete a technical report by the end of the sprint.

\begin{figure*}[!hm]
\centering
\includegraphics[width=\textwidth]{Frontend_login.jpg}
\caption{The web front-end login logic flow diagram.}
\label{fig:frontend_login}
\end{figure*}

\section{Costing Analysis Table}
\label{appen:costing_analysis}
% Table generated by Excel2LaTeX from sheet 'Sheet1'
\begin{table}[h!]
  \centering
  \caption{The costing analysis details for both compressed and uncompressed data. The compressed data for a 20 point file is 159 bytes and for uncompressed 601 bytes.}
    \begin{tabular}{rrr}
    \addlinespace
    \toprule
    \textbf{Bandwidth} & Price per MB: & R 2.00 \\
    \midrule
          & Price per B: & \textbf{1.90735E-06} \\
     		 & \textbf{} & \textbf{} \\
          & \textbf{Average:} & \textbf{Compressed:} \\
    Packet size (bytes): & 315   & 156 \\
    Points per Packet: & 10    & 10 \\
    Interval (s): & 10    & 10 \\
    Drive time (min): & 60    & 60 \\
          &       &  \\
    Total Points: & \textbf{360} & \textbf{360} \\
    Total Packets: & \textbf{36} & \textbf{36} \\
    Total Bytes: & \textbf{11340} & \textbf{5616} \\
    Total Cost: & \textbf{R 0.02} & \textbf{R 0.01} \\
    \bottomrule
    \end{tabular}%
  \label{tab:addlabel}%
\end{table}%



\clearpage
\section{Front-End Flow Diagrams}



\label{appen:frontend}
\begin{figure*}[!hb]
\centering
\includegraphics[width=\textwidth]{Frontend.jpg}
\caption{The web front-end logic flow diagram}
\label{fig:frontend}
\end{figure*}

\end{document}
